Hız, tasarım odaksızlık, çok özellik, az kalite, yine hız…

Çalışırken sürekli bir koşturmaca, yoğunluktan işlere odaklanamama, seri ve verimsiz geçen toplantılar, geçen hafta odaklanılan işlerin ne olduğunu bile hatırlayamama gibi problemlerle boğuşuyorsanız, çalışma şeklinizde bir problem var demektir. Bir kaç soru sorabiliriz bu durumda;

• Bir iş bitince hemen yenisine mi geçiyoruz? (Geliştirdiğimiz özellikleri ölçümleyecek ve optimize edecek vakit ayırıyor muyuz?)
• Hız bizi kullanıcımızdan ne kadar uzaklaştırıyor? (Hızla giderken kullanıcı problemlerini doğru analiz edecek vakti yaratıyor muyuz? yoksa kendi fantezilerimizin peşinde mi koşuyoruz?)
• Bazen eklemek yerine üründen bir şeyler de çıkarıyor muyuz? (Yoksa ürün özellik çorbasına mı dönmüş?)

“Bir tasarımcı, ekleyecek bir şey kalmadığında değil, çıkarak bir şey kalmadığında mükemmele ulaşmıştır.”

Antoine de Saint-Exupery

Bu soruları sormak ürünlerimize karşı genel bir bakış açısı kazandıracaktır. “Bir sürü özelliğimiz var, hangisi ne kadar işe yarıyor?” “Çok fazla şeye odaklanıp kaliteden ödün mü veriliyor?”, “Tüm bunların sonucunda ürünün kullanıcıların gözündeki imajı nasıl bir şeye benziyor?” gibi daha kapsayıcı sorular için fikirler geliştirmemize yarıyor.

Çevik mi, hızlı mı?

Çevik ürün geliştirme felsefesinin temelinde optimum hız ile maksimum verimliliği yakalamak vardır. Felsefedeki çeviklik, değişimlere hızlı yanıt vermek anlamını taşırken, şirketler bunu derinlemesine anlamadan, hız kısmını cımbızlayıp, rüzgarı arkalarına alma yolunu seçiyorlar. Böylelikle hız temel amaç oluyor, felsefenin temelindeki bazı şeyler unutuluyor ve sonucunda şöyle hatalar yapılıyor;

• Kullanıcı ihtiyaçlarını analiz etmek ve değişen ihtiyaçlara cevap vermek yerine kullanıcıyı tanıdığını zannedip, hızlı çözümler üretmeye çalışmak,
• İşi küçük parçalara bölmek yerine, büyük yığınlar halinde çalışmak (Örn: bir uygulamanın arama deneyimini, küçük, kullanılabilir parçalar halinde yayına almak ve her küçük parçanın kullanıcı deneyimini ölçümlemek yerine, komple ve tek seferde yayına almak için uğraşmak),
• Daha hızlı olabilmek adına işbirlikçi olmaktan uzaklaşmak, hızlı kararlar almak.

“Kullanıcı deneyimi bizi yavaşlatıyor…” algısı

UX süreçleri elbette zaman alır, fakat problemi tanımlamak sürecin en önemli aşamasıdır ve bu zaten zaman ayrılması gereken bir durumdur.

“Eğer bir problemi çözmek için bir saatim olsaydı, 55 dakikasını probleme, 5 dakikasını çözüme ayırırdım.”

Albert Einstein

Fakat yine de bu süreler bazı yöntemler kullanılarak kısaltılabilir. Örneğin; gerilla kullanılabilirlik testi ve gerilla kullanıcı araştırması yöntemleriyle. Her ikisi için de amaç kısa zamanda, düşük maliyet ile problemi tanımlamak ya da hipotezleri test etmek. Size her ikisi için de kısa ve gerçek örnekler vereyim.

Diyelim ki süreç içerisinde kullanıcı görüşmeleri yapmanız gerekiyor ve vaktiniz kısıtlı. Birilerini şirkete davet etmek ya da görüşme için dışarı gitmek zaman alıcı olacaktır. Tam da böyle bir durumdayken denediğim bir yöntemi anlatmak istiyorum: Önce şirketteki veri analizi uzmanına ulaştım ve personalarımızın özelliklerine göre belirlenen kriterlerde 5’er kişinin (toplamda 30 kişi) e-posta adreslerini rica ettim. Hızlıca bir e-posta kalıbı hazırladım ve herkese gönderdim. Yazdığım e-postada, ürünün deneyimini iyileştirmek için çalıştığımızı, eğer yardımcı olmak isterlerse en fazla 15 dakika sürecek çevrimiçi bir görüşme yapmak istediğimi söyledim. Hepsi dönmese de, ihtiyacım olan kadarı geri dönüş yaptı ve seve seve yardım edeceklerini söylediler.

Bu noktada en zor olan kısım, zaman planlaması. Hiç bir planlamayı müşteri hizmetlerine bırakmadım çünkü süreci yavaşlatacağını düşünüyordum. Takvimimi açarak, e-postaya ilk cevabı veren kişiyi her ikimiz için de uygun olan ortak zamanlara eklemeye başladım. Bazen öğlen yemeği saatlerine, bazen iş çıkışına bile denk getirebiliyordum. Toplamda 1 haftamı aldı. Görüşmelere genelde 2 kişi giriyorduk ve ben özellikle farklı alanlardan takım arkadaşlarımı görüşmelere dahil ediyordum; mesela yazılımcıları, pazarlama uzmanlarını, ürün yöneticilerini… Böylece hem not almama yardımcı oluyor, hem de ilk elden kullanıcı problemlerini dinlemiş oluyorlardı. Daha da önemlisi; süreç sonunda kullanıcı deneyimi tasarımı konusunda daha iyi bir fikre sahip olduklarını da gözlemledim. Görüşmeler bitince çıktıları düzenleyip bir toplantıda takım arkadaşlarımla paylaştım ve orada üzerinden geçerek kararlar aldık ve hızlıca ilerleyebildik.

Bu örneklerden sadece bir tanesiydi. Odaklanılmış konularla ilgili hızlı veri analizleri yapmak, bazı uygulamalar yardımıyla küçük anketler yapmak, e-posta yoluyla anketler yapmak, müşteri hizmetleriyle iletişime geçip çok fazla gelen şikayetlerin listesini rica etmek vb. gibi çalışmalar da süreci hızlandırmaya yardımcı olan unsurlar olarak not edilebilir.

Gerilla kullanılabilirlik testindeyse, test senaryosunu hazırlayıp, üretilen tasarım hipotezlerini interaktif prototipe çevirdikten sonra, etraftaki kafelerden birine gidip bazı insanlardan 5 dakikalarını istedim. Çoğu yine olumlu yaklaştı ve senaryolara uyarak testleri tamamladım. Zaten 5-6 kişiden sonra tekrar ediyor genelde sorunlar. Problemler 5-6 kişide tekrar ettikten sonra bilgisayarımı açıp, o problemler için hızlıca yeni çözümler üreterek tekrar test ettim. Problemler çözüme kavuşana kadar devam ettim ve 1-2 saat içerisinde epeyce bir kullanılabilirlik problemi çözmüş oldum. Tüm bu bahsettiklerim hem hızlı hem de maliyetsiz.

Kullanıcı deneyimi tasarımı süreçleri doğru uygulandığında ürün geliştirme süreçlerini yavaşlatmaz, şirketi ve hatta dünyayı yararsız özelliklere, servislere ve ürünlere harcanan kaynaktan ve zamandan tasarruf ettirir.

Tepeden inme seri işler

Bazen yöneticiler gelir ve bir şeylerin uygulanmasını ister;

• “Şunu şunu yapacağız ve 1 sprintte bitirmemiz lazım.”
• “Bu hafta bitirmemiz lazım, kullanıcı araştırmasına/testine vaktimiz yok.”
• “Bunun tasarımı uzun sürmez, sonra hızlıca kodlanır, çıkarız canlıya.”
• “Tasarımları bitmedi mi daha? Neden bu kadar uzun sürdü ki?”

Bu maddelere biraz kafa yorunca, bir ortak noktalarının olduğunu görebilirsiniz: Aslında burada takımlara çözülmesi gereken bir problem verilmiyor (ki belki ortada bir problem bile yok), aksine direkt olarak çözüm önerisi dayatılıyor. Çünkü şirketin problemlerle ve kullanıcılarla uğraşacak vakti yoktur. Çünkü takıma çözmesi için bir şeyler verirlerse işler çok uzayacaktır! Onlar böyle düşünüyor, bana kızmayın.

Fakat yöneticilerin gözünden bakmaya çalışırsak; belki de ekipler de güven veremiyor olabilirler. Bence buradaki önemli noktalardan bir tanesi “Neden?” sorusunu sormak. Ekiplerin yaptıkları işlere dair “Peki bunu neden yapıyoruz?” diye sormaları ve bu noktada çözüme değil, problemin kendisine odaklanarak sorgulamaları, yöneticilerde “Ne versek uyguluyorlar zaten” algısını kıracaktır ve çözüm yerine, çözülmesi gereken problemlerle gelecek güveni bulacaklardır. Bu, zamanla onları da çözüm odaklılıktan, problem odaklı düşünmeye başlatacaktır. Bu anlayış benimsendikçe, hız odaklı olmak yerine, kalite odaklı olmak da kaçınılmaz olacak.

Sonuç

Geliştir, ölç, öğren (build, measure, learn) döngüsü içerisinde devam etmeyen bir ürün geliştirme süreci sonunda, üstüne bir de kontrolsüz hız dahil olduğunda, nitelik değil nicelik odaklı bir ürün çıkması kaçınılmaz bir hal alabiliyor. Kısa sürede çok fazla özellik geliştirmek hem o özelliklerin kullanıcı açısından değerini tehlikeye atıyor, hem de ürün bir kaosa dönüştüğü için, ekip kaynak ve zaman harcayarak, üst üste biriken problemlerle boğuşmak zorunda kalıyor.

Başarıyı sadece iş tamamlamak ve hız ile ölçmek yerine, geliştirmelerin kullanıcıya faydasını ölçümlemek, en az kaynak kullanımı ve optimum hızla en büyük değeri üretmek ile ölçmeliyiz.